How does this fix #676? In fact, if you don't have read perms for the folder, how would the chmod even succeed?

@nhooyr if I got the writing part for this right, you still have ownership in the folder because you're inside coder. I've used this before in my Coder images and they seem to work. We can still change the modes since we have ownership on it.

@nhooyr, for what it is worth I would like to see this approved or denied as I am experiencing the same issue:

#454 (comment)

you still have ownership in the folder because you're inside coder.

Then why do you need to make it group editable if you have ownership?

Apparently this does not mandate the ownership well for bind mounts for some reason so explicitly setting them as RW is the only way to make sure you can write changes from container to host @nhooyr.

We need to know what the reason is before merging this. The only reason I see is if the directory outside of the container has a different owner than uid 1000 at which point you should be changing the directory outside of the container or run code-server as a different user instead of uid 1000. See #640

We need to know what the reason is before merging this. The only reason I see is if the directory outside of the container has a different owner than uid 1000 at which point you should be changing the directory outside of the container or run code-server as a different user instead of uid 1000. See #640

it will "Permission denied" on docker

Even if we set it to UID1000, the permissions in the bind mounted folder is not the same, therefore, we should force writes and reads on the bind folder so we can write to the folder.

There is a inherent reason we do this as well, permissions is irrelevant to the host because its a container-specific permission. There will be no impact on security since it only applies to the container.

There is a inherent reason we do this as well, permissions is irrelevant to the host because its a container-specific permission. There will be no impact on security since it only applies to the container.

I don't think this is true, if its mounted in, then any changes to it will affect the folder outside the container. Docker doesn't have user namespacing enabled by default, so the UIDs/GIDs inside the container are the same as the UIDs/GIDs outside.

Can you show the perms on the folder you're having trouble with and then show the UID the container is running as? Do a ls -la and post it here.

In fact can you open a new issue? A issue is better suited for debugging than this PR.

Revisiting this PR due to GH-992. Impact is considered major.

There is a inherent reason we do this as well, permissions is irrelevant to the host because its a container-specific permission. There will be no impact on security since it only applies to the container.

I don't think this is true, if its mounted in, then any changes to it will affect the folder outside the container. Docker doesn't have user namespacing enabled by default, so the UIDs/GIDs inside the container are the same as the UIDs/GIDs outside.

Can you show the perms on the folder you're having trouble with and then show the UID the container is running as? Do a ls -la and post it here.

@marcdumais-work Provides a explanation over at our friends at Theia, which you can find here.

The permission issues you have are expected, and a generic Docker issue when sharing files between a host and container using a volume. What happens is that inside the container, the theia user is different than your user on the host. You can use the id -u and id -g commands to confirm (respectively user id and current main group id) - the user name/group names do not matter, just the ids, when it comes to permissions on Linux.

If you are looking for a solution specifically for yourself, one option would be to modify the image you use and have the theia user created in the image using your host uid/gid, and then you could access the same files from both without these issues.The permission issues you have are expected, and a generic Docker issue when sharing files between a host and container using a volume. What happens is that inside the container, the theia user is different than your user on the host. You can use the id -u and id -g commands to confirm (respectively user id and current main group id) - the user name/group names do not matter, just the ids, when it comes to permissions on Linux.

So essentially speaking in the terms of Unix permission model we do not have the ability to write to that folder even if we own /projects because the file contents isn't ours. Overriding permissions in the container isn't a real security issue since we're only mounting a specific folder. Giving write access on that folder explicitly is the only safe workaround. Another workaround is to have the user write it under the root group. We shouldn't worry about the container writing where its not supposed to because we are supposed to write there, but the workaround is intended so they can write normally to a mounted folder or a PV.

This wouldn't work regardless. If we do something like this, it has to be done in the entrypoint.sh, not just for the top level project directory which will have the real project directory mounted in as even if the user owns the top level project directory, they still won't be able to access files in a subdirectory.